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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by Joint Technical Conmiittee (JTC) Broadcast of the European 
Broadcasting Union (EBU), Comite Europeen de Normalisation ELECtrotechnique (CENELEC) and the European 
Telecommunications Standards Institute (ETSI). 

NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the 
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body 
by including in the Memorandum of Understanding also CENELEC, which is responsible for the 
standardization of radio and television receivers. The EBU is a professional association of broadcasting 
organizations whose work includes the co-ordination of its members' activities in the technical, legal, 
programme-making and programme-exchange domains. The EBU has active members in about 
60 countries in the European broadcasting area; its headquarters is in Geneva. 

European Broadcasting Union 

CH-1218 GRAND SACONNEX (Geneva) 

Switzerland 

Tel: +41 22 717 21 11 

Fax: +41 22 717 24 81 

Founded in September 1993, the DVB Project is a market-led consortium of public and private sector organizations in 
the television industry. Its aim is to establish the framework for the introduction of MPEG-2 based digital television 
services. Now comprising over 200 organizations from more than 25 countries around the world, DVB fosters market- 
led systems, which meet the real needs, and economic circumstances, of the consumer electronics and the broadcast 
industry. 
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Scope 



The present document specifies the signalHng and the transport of TV- Anytime information over an always-on 
bi-directional IP network. The specification allows for metadata describing both Content on Demand and live services 
delivered over any type of network using DVB specifications (e.g. DVB-T, DVB-S, DVB-IP). It can be used to develop 
a Broadband Content Guide, i.e. a content guide that is delivered over an always-on bi-directional IP network. 

The present document is an addendum to TS 102 034 [4]. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 
cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference. 

For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably, 
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the 
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the 
method of access to the referenced document and the full network address, with the same punctuation and use of upper 
case and lower case letters. 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI TS 102 323: "Digital Video Broadcasting (DVB); Carriage and signalling of TV- Anytime 

information in DVB transport streams". 

[2] ETSI TS 102 822-3-2: "Broadcast and On-line Services: Search, select, and rightful use of content 

on personal storage systems ("TV-Anytime"); Part 3: Metadata; Sub-part 2: System aspects in a 
uni-directional environment". 

[3] ETSI TS 102 822-3-1: "Broadcast and On-line Services: Search, select, and rightful use of content 

on personal storage systems ("TV-Anytime"); Part 3: Metadata; Sub-part 1: Phase 1 - Metadata 
schemas". 

[4] ETSI TS 102 034: "Digital Video Broadcasting (DVB) Transport of MPEG-2 TS Based DVB 

Services over IP Based Networks". 

[5] IETF RFC 1950: "ZLIB Compressed Data Format Specification version 3.3". 

[6] IETF RFC 1951: "DEFLATE Compressed Data Format Specification version 1.3". 
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[7] ETSI TS 102 822-6-1: "Broadcast and On-line Services: Search, select, and rightful use of content 

on personal storage systems ("TV- Anytime"); Part 6: DeHvery of metadata over a bi-directional 
network; Sub-part 1 : Service and transport" . 

[8] W3C Note (08 May 2000): "Simple Object Access Protocol (SOAP) 1.1". 

[9] ISO/IEC 13818-1: "Information technology - Generic coding of moving pictures and associated 

audio information: Systems". 

[10] ISO/IEC 23001-1 (MPEG-B): "Information Technology - MPEG Systems Technology - Binary 

MPEG format for XML". 

[11] ETSI EN 300 468: "Digital Video Broadcasting (DVB); Specification for Service Information (SI) 

in DVB systems". 

[12] IETF RFC 2326: "Real Time Streaming Protocol (RTSP)". 

[13] ISO 8601 (2004): "Data elements and interchange formats - Information interchange - 

Representation of dates and times". 

[14] IETF RFC 2616: "Hypertext Transfer Protocol - HTTP/1.1". 

2.2 Informative references 

Not applicable. 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

Content on Demand (CoD): program provided at the request of the end user for direct consumption (real-time 
streaming) or storage 

NOTE: The user could be a person or a PVR or some other entity. 

content provider: entity that owns or is licensed to sell content or content assets 

delivery network: network connecting the delivery network gateway and service providers 

Delivery Network Gateway (DNG): device that is connected to one or multiple delivery networks and one or multiple 
home network segments 

DVB -IP service: DVB service provided over IP or content on demand over IP 

DVB service: as defined by DVB, "a sequence of programmes under the control of a broadcaster which can be 
broadcast as part of a schedule" 

event: grouping of elementary broadcast data streams with a defined start and end time belonging to a common service 

EXAMPLE: First half of a football match, News Flash, first part of an entertainment show. 

Home Network End Device (HNED): device that is connected to a home network and which typically terminates the 
IP based information flow (sender or receiver side) 

package: collection of DVB services marketed as a single entity 

program: collection of program elements 

NOTE: Program elements may be elementary streams. Program elements may have a common time base for 
synchronized presentation. 
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Service Provider (SP): entity providing a service to the end-user 

NOTE: In the context of the present document, SP will mean a Service Provider providing DVB -IP services. 

SP offering: set of streams or services a Service Provider proposes to the end-user 

Transport Stream: data structure defined in ISO/IEC 13818-1 [9] 

TS Full SI: transport stream with embedded service information as defined by DVB in EN 300 468 [11] with the 
exception of the network information table NIT 

NOTE: This table may be omitted as it has no meaning in the context of IP services. 

TS - Optional SI: A transport stream with MPEG PSI (PAT and PMT tables) as defined in ISO/IEC 13818-1 [9] 

NOTE: All other MPEG-2 and DVB tables are optional. 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

BCG Broadband Content Guide 

BiM Binary format for Multimedia description streams 

CoD Content on Demand 

CRI Content Referencing Information 

CRID Content Reference IDentifier 

DNG Delivery Network Gateway 

DVB Digital Video Broadcasting 

DVBSTP DVB SD&S Transport Protocol 

HNED Home Network End Device 

HTTP Hyper Text Transfer Protocol 

IMI Instant Metadata Identifier 

IP Internet Protocol 

IPI Internet Protocol Infrastructure 

MPEG Moving Pictures Expert Group 

RAR Resolving Authority Record 

RNT RAR Notification Table 

RTSP Real Time Streaming Protocol 

SD&S Service Discovery and Selection 

SOAP Simple Object Access Protocol 

SP Service Provider 

URL Uniform Resource Locator 

XML extensible Markup Language 



Delivery of BCG data 



BCG data MAY be delivered in one of two ways: 

• Container-based: 

via multicast (i.e. pushed); 
via unicast (i.e. pulled). 

• Query: 

via unicast. 

The IPI-1 interface SHALL support the container-based mechanism, both via multicast and unicast. It MAY 
additionally support the query mechanism. 
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On all networks there SHALL be at least one BCG provider that supports the container based download mechanism. 
Additionally, this provider MAY support the query mechanism. 

For clarification, the query mechanism is optional for both Service Providers and HNEDs. 

The container based download mechanism uses the Data Delivery Unit, as specified in clause 4.1.1.3, delivered via the 
mechanisms specified in clause 4.2. 

The query mechanism is specified in clause 4.3. 

4.1 Container-Based Delivery 

4.1.1 Definitions 
4.1.1.1 Container 

A container shall carry either a RNT, one or more CRI structures or Metadata. Each container is distinguished by a 
unique identifier, which is the container_id. Table 1 shows the clauses in the present document where the container 
format, according to each type of data carried, is defined. 

Table 1 : Container Format Definitions 



Type of data carried 


Container Format Definition 


RNT 


Clause 5.1 in the present document 


CRI structures 


TS 102 323 [1], clause 7.3.1.3 


Metadata 


TS 102 323 [1], clause 9.3 



The type of data that the container carries determines the scope and format of the structure values. 

4.1 .1 .2 Compression wrapper 

The compression_wrapper allows a container to be carried in a compressed or uncompressed format. The syntax of the 
compression_wrapper is defined in table 21, clause 7.3.1.5 of TS 102 323 [1]. The compression_wrapper shall always 
be present, whether or not the container is compressed. 

The semantics of the fields of table 21, clause 7.3.1.5 of TS 102 323 [1] are modified as follows: 

• container(): See clause 4.1.1.1 for the definition of the container structure. 

NOTE: This definition differs from TS 102 323 [1], where the compression wrapper may contain CRI structures 
only. 

• compression_structure: This shall contain a container (see clause 4.1.1.1) encoded as a Zlib stream 

(as defined in RFC 1950 [5]). When present, the Zlib stream shall have its compression method nibble set to 
"1000", indicating use of the Deflate compression algorithm as specified in RFC 1951 [6]. 

4.1.1.3 Data Delivery Unit 

A Data Delivery Unit is a container, as defined in clause 4.1.1.1, within a compression wrapper as defined in 
clause 4.1.1.2. 
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4.1.2 Transport 



4.1.2.1 



SD&S Information Data Types 



In addition to the Payload ID values defined in TS 102 034 [4], table 1, clause 5.2.2.1, the values defined in table 2 shall 
be used for the BCG Data Delivery Units. 

Table 2: BCG Payload ID values 



Payload ID value 


Payload type carried 


OxA1 


DVB-TV A-init message (clause 7.3 in the present document) 


0xA2 


TVAMain fragment (clause 7.4 in the present document) 


0xA3 


TV-Anytime metadata data container (clause 9.2.2 of TS 102 323 [1]), value "d" in table 47) 


0xA4 


TV-Anytime metadata index container (clause 9.2.2 of TS 102 323 [1], value "i" in table 47) 


0xA5 


Both TV-Anytime metadata data and index container (clause 9.2.2 of TS 102 323 [1], 
value "b" in table 47) 


0xA6 


RNT (clause 5.1 in the present document) 


0xA7 


CRI structure (clause 5.3 in the present document) 


0xA8-0xAF 


Reserved 



4.1.2.2 



Transport mechanisms 



This clause specifies the protocols that are used to transport the BCG information. Two mechanisms are defined, one 
for multicast and one for unicast. 

The protocol DVB SD&S Transport Protocol (DVBSTP), as specified in clause 5.4.1 of TS 102 034 [4], shall be used 
to transport BCG information over multicast. 

The protocol HTTP [14] shall be used to transport BCG information over unicast. 

The two transport mechanisms shall be interchangeable in all steps and carry the same content encoded in the same 
way. 



4.1.2.2.1 



Protocol for Multicast Delivery of BCGs 



For the push model delivery of BCGs, the protocol DVBSTP, as defined in TS 102 034 [4], clause 5.4.1.2, shall be used 
to transmit Data Delivery Units, as defined in clause 4.1.1.3 of the present document. Additional semantics are defined 
for the following fields: 

• Payload ID: The Payload ID shall be encoded as specified in table 2 of the present document. 

• Segment ID: If the Payload ID value is Ox A3, 0xA4 or OxA5, then this field has the semantics of the 
container_id defined in TS 102 822-3-2 [2], clause 4.5.1.3. If the Payload ID value is 0xA7 then this field has 
the semantics of the container_id defined in TS 102 323 [1], clause 7.3.1.1. 

• Segment Version: If the Payload ID value is OxA3, 0xA4 or OxA5, then this field has the semantics of a 
container version identifier defined in TS 102 822-3-2 [2], clause 4.5.1.2. 

• Compression (Compr): Additional compression values are defined in table 3. 

The field value of "001" is used to signal the encoding defined in the present document, which will be either BiM [10] 
for XML data or a specific binary representation for non XML data (RNT, CRI etc.). Use of other values in the 
compression field is not defined. 

Table 3: Additional Compression Values 



Compression value 


Meaning 


Total Segment Size Meaning 


001 


Either BiM or the specific binary 
representation defined in the 
present document 


Transmitted Size 
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4.1.2.2.2 



Protocol for Unicast Delivery of BCGs 



In the pull model of delivery of BCGs, the HTTP [14] protocol shall be used for all communication between the HNED 
and the BCG server(s). 

When the HNED requests BCG information, it shall use the format defined in TS 102 034 [4], clause 5.4.2. The 
Payload ID values used shall be as defined in table 2 of the present document. The segmentID values shall have the 
same semantics as defined in TS 102 034 [4], clause 5.4.1.2. The BCG server(s) shall return Data Delivery Units, as 
defined in clause 4.1.1.3 of the present document. 

When the HNED requests BCG information, it shall use the following format: 

"GET /dvb/sdns/bcg_request HTTP/1.1" CRLF 
"Host: " host CRLF 

The bcg_request shall comply with the following format: 

bcg_request = bcg?Payload="PayloadId"&Segment="SegmentItem" 

where: 

Payloadid = OCTET; any hex number from 0x0 to Oxff 
Segmentid = 4*4 HEXDIG;any hex number from 0x0000 to Oxffff 
Segment Item = Segmentid 0*1 ('& 'Vers ionNumber) 

Segmentltem is a Segmentid with an optional field for the version number. 

VersionNumber = OCTET; any hex number from 0x0 to Oxff 

For example, the following request can be constructed to request the index list structure (see TS 102 323 [1], 
clause 9.2.2): 

"GET /dvb/sdns/bcg?Payload=A4&Segment=0000 HTTP/1.1" CRLF 
"Host: " host CRLF 

The HTTP headers returned with the data shall be: 

Content -encoding : x-dvb-bcg-ip 

4.2 Query mechanism 

The query mechanism for BCG acquisition is described in this clause. 

When the query mechanism is used, it SHALL be implemented according to TS 102 822-6-1 [7] and the requirements 
described in this clause. TS 102 822-6-1 [7] describes four SOAP methods. The version of SOAP [8] used SHALL 
be 1.1. 

Table 4 shows the status of these methods within the present document. 

Table 4: Requirements for Service Providers and HNEDs relating to SOAP methods 

as defined in TS 102 822-6-1 





Service Provider 


HNED 


get Data 


M 


M 


describe Get Data 


M 


M 


submit Data 








describe_Submit_Data 


(if submit_Data not supported) 
IVI (if submit Data supported) 
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5 Content Resolution 

Content resolution is performed as in TS 102 323 [1], with the following additional constraints. 

5.1 RNT (Resolution Provider Notification Table) 

This table shall be carried inside a Data Delivery Unit, as defined in clause 4.1.1.3 of the present document. 

The syntax and semantics of table 1 of clause 5.2.2 of TS 102 323 [1] shall be used, but deleting all the fields preceding 
the common_descriptors_length field, except the last 4 reserved bits. This removes all references to table sections, 
context_id and context_id_type, which are not relevant to the present document 

5.2 RAR over IP descriptor 

The RAR over IP descriptor defined in TS 102 323 [1], clause 5.3.6 shall have the following additional semantics: 

• urljength: The length of the URL. A length of can be used to indicate that the CRI structures shall be 
transmitted via the URL that is currently used. 

• url_char: If present, this field shall contain a URL. The rules governing the encoding of an URL shall be as 
defined in clause 6.2 of TS 102 323 [1]. 

5.3 CRI structures 

CRI structures are used to resolve a GRID into one or more locator(s) or CRID(s). 

The format of CRI structures defined in TS 102 323 [1], clause 7.3.1.3 shall be used. 

Either the URI or the DVB binary locator shall be used, as defined in ETSI TS 102 323 [1], clause 7.3.2.3.2. The syntax 
of the locator for a DVB -IP service shall be as defined in clause 8 of the present document. 

This structure shall be carried inside a Data Delivery Unit, as defined in clause 4.1.1.3 of the present document. 

The container carrying the cri_index structure, which is the first structure required by the receiver, shall have its 
Segment ID set to 0x0000, as specified by TS 102 323 [1], clause 7.3.1.1. 

6 Profile of TV-Anytime Metadata for BCG 
6.1 Introduction 

TS 102 822-3-2 [2] provides several options for how to structure descriptions of program, group and location 
information. The present clause defines the options that are either mandatory, optional or not used for BCG information. 
The profile as specified in TS 102 323 [1], clause 8 shall apply unless explicitly stated below. 

NOTE: The present document does not provide any profiling for metadata delivered by other means. 



6.2 Summary 



The fragments defined in TS 102 323 [1], clause 8.2 shall be used. The following clauses provide further details as 
needed. 

6.3 Programlnformation fragment 

The Programlnformation fragment shall be defined as in TS 102 323 [1], clause 8.3. 
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6.4 Grouplnformation fragment 

The Grouplnformation fragment shall be defined as in TS 102 323 [1], clause 8.4. 

6.5 Schedule fragment 

The Schedule fragment shall be defined as in TS 102 323 [1], clause 8.5. 

6.6 Servicelnformation fragment 

If an optional field is not specified in the BCG, the corresponding information shall be inferred from the SD&S 
information of that service. If an optional field is specified both in the BCG and the SD&S information, then the field of 
the BCG shall be used. 

The Name element (mandatory at BCG level) may be an empty element, in which case it shall be inferred from the 
SD&S information of that service, i.e. the SI Name defined in clause 5.2.6.2.2 of TS 102 034 [4]. If the Name element 
(mandatory at BCG level) is filled, then this field shall be used. 

If the Logo element is present, it shall contain a URL that points to an image file. 

The value of serviceld in Servicelnformation fragment is equal to the ServiceName of the corresponding service in 
SD&S records, whose syntax is given in clause 5.2.1.2 (Service Name or Service id) of TS 102 034 [4]. This insures a 
unique mapping between SD&S and BCG records for a service. 

For instance, if the ServiceName of a service from the Service Provider sport-provider is 
"extreme-sport.sport-provider.com" in SD&S, the serviceld in BCG shall also be "extreme-sport.sport-provider.com". 

6.7 OnDemandProgram fragment 

If the Instance Description field is present, its elements shall override the matching elements defined in the 
corresponding Program Information fragment. 

The PublishedDuration, StartOf Availability, EndOfAvailability, FirstAvailability and LastAvailability elements in the 
OnDemandProgram element are optional. If the PublishedDuration element is not present, the value may be found in 
the Programlnformation fragment. If not present, it is undefined. If StartOf Availability is not present, then the value of 
"now" is assumed. If EndOfAvailability is not present, then the value of "indefinitely" is assumed. These 
recommendations are summarized in table 5. 

Table 5: Default values for OnDemandProgram elements 



Element 


Default values 


PublishedDuration 


The value of the Programlnformation fragment, if present, else undefined 


StartOfAvailability 


Now 


EndOfAvailability 


Indefinitely 


FirstAvailability 


Undefined 


LastAvailability 


Undefined 



The Program element shall be present and shall contain a CRID that can be found in the ProgramlnformationTable and 
this CRID should also be present in the CRI. 

The ProgramURL element may be present, to provide the location. If the ProgramURL element is present, it shall 
contain a RTSP URL. The dialog with the RTSP server shall comply with TS 102 034 [4], clause 6. 

The CRI shall be considered the authoritative source of CRID to location information. 

The InstanceMetadatald (IMI) may be present and when present the same IMI shall be available in the CRI. 

NOTE: The CRI can return a "not yet resolvable" flag in case the location is not yet available, but will be 
provided later. In this case it is recommended that the "StartOfAvailability" element is sent. 
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6.8 Purchase Information fragment 



The Purchaselnformation fragment shall be defined as in TS 102 822-3-2 [2], clause 4.3.1.10 and TS 102 822-3-1 [3] 
clause 6.3.4 (complex type PurchaseltemType), with the following recommendations: 

• A purchaseList element shall contain at least one Purchaseltem or PurchaseldRef. 

• Exactly one of the price attributes unit or currency shall be present. 

• If a PurchaseldRef is used, it shall contain a reference to a Purchase element that can be found in the 
TransactionlnformationTable. 

If the PricingServerURL is used, the returned information shall be a Data Delivery Unit containing a Pricinglnformation 
fragment. 



7 TV-Anytime Fragments 

7.1 Fragment encapsulation 

TV-Anytime fragments shall be delivered in Data Delivery Units, as defined in clause 4.1.1.3 of the present document, 
i.e. they shall be carried in containers within a compression wrapper and delivered either using HTTP or DVBSTP. 

7.2 Fragment encoding 

TV-Anytime fragments shall be encoded with BiM [10], as defined in TS 102 323 [1], clause 9.4. 



7.3 DVB-TVA-init message 



The DVB-TVA-init message shall be conformant to the DVB profile of the TVA MPEG-7 profile (BiM) as defined in 
TS 102 323 [1], clause 9.4.2.1. 

The DVB-TVA-init message shall be delivered, as defined in table 2 of the present document, using the Payload ID 
value OxAl. 



7.4 TVAIVIain fragment 



The TVAMain fragment, defined in TS 102 822-3-2 [2] contains the initial description of a TV-Anytime document. The 
transmission of this fragment is optional, as specified in TS 102 323 [1], clause 9.4.2.2. 

If transmitted, the TVAMain fragment shall be delivered as defined in table 2 of the present document, using the 
Payload ID value 0xA2. 

If not transmitted, the default TVMain fragment shall be used by the HNED, as specified in TS 102 323 [1] 
clause 9.4.2.2. 



8 Locator 

The syntax of the locator for DVB -IP services shall be a URI with the following additional constraints. 

For services and content items available through RTSP [12], the following format shall be used: 

rtsp:// <host>r:port1 [/absolute_path] [;;<TVA_id>] [[@time_duration] I [@<window_start>;<window_end>]] 

where host is the address of the service, TVA_id and time_duration are as specified in TS 102 323 [1], clause 6.4, and 
window_start and window_end are represented using ISO 8601 [13]. 
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For instance, the following sample shows a URI referencing a stream available using RTSP: 

rtsp://www.foo.com:9090/mycontent@2006-01-01T00:00:00Z;2006-01-31T23:59:59Z 

For services and content items available by joining a multicast session where the stream is available over rtp, the 
following format shall be used: 

rtp://<host_address>[:port] [;source_address] [; ;<TVA_id>] [[ @ time_duration] I 
[ @ <window_start>;<window_end>] ] 

where host_address is the multicast address of the service, source_address is the optional address of the multicast source 
host, TVA_id and time_duration are as specified in TS 102 323 [1], clause 6.4, and window_start and window_end are 
represented using ISO 8601 [13]. 

For instance, the following sample shows an URL referencing a stream available over multicast: 

rtp://224.L2.3:1234;;398298@2006-01-23T02:00:00Z-PT01H34M 

For services and content items available by joining a multicast session where the stream is available directly over udp, 
the following format shall be used: 

udp://<host_address>[:port] [;source_address] [; ;<TVA_id>] [[ @ time_duration] I 
[ @ <window_start>;< window_end>] ] 

where host_address is the multicast address of the service, source_address is the optional address of the multicast source 
host, TVA_id and time_duration are as specified in TS 102 323 [1], clause 6.4, and window_start and window_end are 
represented using ISO 8601 [13]. 

For instance, the following sample shows an URL referencing a stream available over multicast: 

udp://224.1.2.3:1234;;398298@2006-01-23T02:00:00Z-PT01H34M 



Usage of RTSP Methods 



Where RTSP is used to access content on demand, the RTSP DESCRIBE (TS 102 034 [4], clause 6.3.1.2) and 
ANNOUNCE Methods (TS 102 034 [4], clause 6.3.1.1) shall use an XML complex structure of the TV-Anytime type 
BasicContentDescriptionType. The namespace shall be specified at the start of the XML document, with the default 
being as specified in TS 102 323 [1]. 

The data shall be carried in unicast mode, as defined in TS 102 034 [4], clause 5.4.2. Specifically, this type shall be 
encoded as defined in clause 7.2, encapsulated as defined in clause 7.1 and the HTTP headers shall be defined as in 
clause 4.1.2.2.2 of the present document. The use of this type shall comply with the profiling set out in TS 102 323 [1] 
and clause 6 of the present document. 



ETSI 



15 



ETSI TS 102 539 VI .2.1 (2008-04) 



History 



Document history 


VI. 1.1 


November 2006 


Publication (based on IPI2042r8) 


Vl.2.1 


April 2008 


Publication 





















ETSI 



